跳到主要内容
Cowers://
全部文章
Agent 架构

LangChain 与 LangGraph 的职责演变

为什么现在讲 Agent 只讲 LangGraph 的 State / Node / Edge，很少再系统讲 LangChain 的 Chain 与 AgentExecutor？不是 LangChain 被取代了，而是 LangGraph 接管了它历史上很大一块「流程编排」职责。

LangChain 与 LangGraph 的职责演变

阅读提示 本笔记讲的是生态内部两套东西的分工，与横向对比其他框架的Agent 常见框架与区别互补；代码怎么分层见Agent 架构：lang 系框架的工程分层。更高层的 Agent Harness 见 Deepagents。

⚠️ = 常见陷阱　🆚 = 对比说明　💡 = 机制或选择建议

目录

核心结论 现在讲 Agent，很多人只讲 LangGraph 的 State、Node、Edge、Conditional Edge、Checkpoint、Interrupt、Subgraph，却很少系统讲以前 LangChain 的各种 Chain、AgentExecutor、Memory。原因不是 LangChain 被完全取代了，而是：LangGraph 接管了 LangChain 过去很大一块「Agent 流程编排」职责。

一、LangChain 与 LangGraph 现在是两层，不是二选一

一句话概括现在的分工：

LangChain = Agent SDK / 组件层
LangGraph = Agent Runtime / 工作流编排层

放进整条生态链看：

Deep Agents
    ↓
LangChain
    ↓
LangGraph
    ↓
LLM Provider

二、为什么复杂 Agent 更适合状态图

以前 LangChain 常见的思路是简单线性调用，可以称之为 Chain：

Prompt
 ↓
LLM
 ↓
Tool
 ↓
LLM
 ↓
Result

但真实的生产 Agent 往往长这样：

用户请求
   ↓
意图判断
   ↓
规划
   ↓
调用工具
   ↓
检查结果
   ├── 成功 → 下一步
   ├── 失败 → 重试
   ├── 信息不足 → 澄清
   ├── 高风险 → 人工审核
   └── 需要其他能力 → 分支执行

它本质已经不是普通 Chain，而是：

State + Node + Edge + Condition + Loop

也就是有状态工作流 / 状态机。因此复杂 Agent 的核心逐渐从 Chain 转向 Graph。

三、LangGraph 负责什么：Agent Runtime 与状态机

LangGraph 更接近一个 Agent Runtime + Stateful Workflow Engine，核心能力：

LangGraph
├── State
├── Reducer
├── Node
├── Edge
├── Conditional Edge
├── Command
├── Send
├── Loop
├── Checkpointer
├── Store
├── Interrupt
├── Human-in-the-loop
├── Subgraph
├── Persistence
└── Durable Execution

重点不是「一个 Tool 怎么定义」，而是整个 Agent 系统如何执行：

             State
               ↓
         classify_node
          ↙        ↘
      search       clarify
        ↓
     evaluate
      ↙    ↘
   retry    answer

LangGraph 负责：当前 State 是什么、Node 怎么执行、Node 之间怎么跳转、什么情况下循环、什么情况下暂停、怎么恢复任务、怎么保存执行状态。

四、LangChain 负责什么：Agent 的 SDK 与组件层

现在 LangChain 更像 Agent 领域的高层 SDK 和标准组件库：

LangChain
├── Model abstraction
├── Messages
├── Tool abstraction
├── create_agent
├── Middleware
├── Structured Output
├── Model Provider Integration
├── Retriever
├── Embedding
└── VectorStore Integration

所以 LangChain 不只是「把 Tool 装进 Agent」，更准确说是：提供 Agent 使用的标准组件、统一接口和现成的 Agent 实现。

五、LangChain 没有被取代的能力

Model 抽象

不用 LangChain 时，要分别面对 OpenAI / Anthropic / Gemini / Qwen 等不同 SDK，各家在 Client、参数、Message 格式、Tool Calling 格式、Streaming 接口、Structured Output 格式上都不一致：

OpenAI SDK   → client + 参数 + 消息 + tool calling + streaming ...
Anthropic SDK → ...
Gemini SDK    → ...
Qwen SDK      → ...

LangChain 提供统一模型抽象：

model.invoke(messages)

上层 Agent 代码不必强绑定某个模型厂商。而 LangGraph 本身并不关心底层是 OpenAI、Claude、Gemini、Qwen、Ollama 还是 vLLM，它只知道「调用这个 Node → Node 返回 State Update」。

六、Tool：LangChain 定义能力，LangGraph 调度执行

两者都能涉及 Tool，但层次不同。

LangChain 更关注「什么是 Tool」：

Tool
├── name
├── description
├── args_schema
├── runtime context
├── return value
└── error

LangGraph 更关注「Tool 应该什么时候执行、执行之后下一步去哪」：

LangChain Tool       LangGraph ToolNode
     ↓                    ↓
   定义能力              执行能力

所以：Tool 的「标准抽象」更偏 LangChain，Tool 的「流程调度」更偏 LangGraph。

七、create_agent：官方替你做好的标准图

对一个标准 ReAct Agent：

LLM
 ↓
是否调用 Tool？
 ├── 是 → Tool → LLM
 └── 否 → END

自己用 LangGraph 写也完全可行：

model_node
    ↓
tools_condition
  ↙          ↘
tools       END
  ↓
model_node

但 LangChain 已经提供 create_agent(model, tools)，本质是官方替你搭好了一个标准 LangGraph Agent：

LangChain create_agent
        ↓
   标准 Agent API
        ↓
CompiledStateGraph
        ↓
LangGraph Runtime

💡 说明 create_agent 构建在 LangGraph 之上、返回一张已编译的状态图。因此「把循环换成图」不是工程发明，而是官方抽象已经走的路。更细节的机制补充见Agent 架构。

八、Middleware：属于 LangChain 的横切能力

很多逻辑不应该直接画进业务 Graph，例如日志、模型重试、模型切换、上下文压缩、动态 Prompt、动态 Tool、权限检查、PII 过滤、Guardrail、人工审批。

如果全用 Node 表示：

load_memory
    ↓
trim_context
    ↓
risk_check
    ↓
model
    ↓
tool_check
    ↓
approval
    ↓
tool

Graph 很快就会变复杂。这些能力更像：

Spring Interceptor
Servlet Filter
FastAPI Middleware
AOP

所以 LangChain 提供 Middleware：

                 Agent
                   │
        ┌──────────┼──────────┐
        ↓          ↓          ↓
 before_model   model     after_model
        │                     │
        └──── Middleware ─────┘

这类属于横切关注点，而不是业务流程。更工程化的落点见中间件一节。

九、能不能只用 LangGraph，不用 LangChain

可以。例如直接这样组织：

业务代码
│
├── OpenAI SDK
├── Pydantic
├── 自己定义 Tool Schema
│
└── LangGraph
    ├── State
    ├── Node
    ├── Edge
    ├── Checkpoint
    └── Store

Node 内可以直接写：

def model_node(state):
    response = client.responses.create(...)
    return {...}

因此 LangChain 是可替换的。但拿掉之后，需要自己处理：Model / Message 抽象、Tool schema、Tool calling 兼容、Structured output、Agent loop、Middleware、Provider integration。所以是否用 LangChain，本质是「要不要用现成的 Agent SDK 与生态」。

十、为什么很多项目是 LangGraph + 原生 SDK

常见架构：

LangGraph
+
OpenAI / Anthropic SDK
+
Pydantic
+
业务代码

原因是现代模型 SDK 本身已经提供很多过去只有 LangChain 才方便提供的能力：

Tool Calling
Structured Output
JSON Schema
Streaming
Reasoning
Built-in Tools
MCP

于是过去 LangChain 很有价值的一些包装——PromptTemplate、OutputParser、LLMChain、ConversationChain、大量 Parser、大量 Chain——现在价值下降了。所以越来越多工程选择「原生模型 SDK + LangGraph」，而不是「全套 LangChain」。

十一、哪些 LangChain 旧内容可以降低优先级

现在学习 Agent，不必重点投入：

LLMChain
SequentialChain
SimpleSequentialChain
ConversationChain
旧 AgentExecutor
旧 Memory 体系
大量老式 Chain
复杂 LCEL 技巧

这些更多属于 LangChain 的历史阶段。

十二、现在值得重点学的 LangChain

LangChain
├── Model abstraction        ★★★★★
├── Messages                 ★★★★☆
├── Tool                     ★★★★★
├── create_agent             ★★★★★
├── Middleware               ★★★★★
├── Structured Output        ★★★★☆
└── Integration ecosystem    ★★★★☆

重点理解各自解决什么：

能力 解决什么
Model 统一不同 LLM Provider
Message 统一模型上下文和消息表示
Tool 统一 Agent 能力描述
create_agent 快速搭标准 Agent Loop
Middleware 横切能力：Guardrail / Logging / Retry / Dynamic Tool / Dynamic Model / Context Engineering / Human Approval

十三、LangGraph 该重点学什么

LangGraph
├── State                    ★★★★★
├── Reducer                  ★★★★★
├── Node                     ★★★★★
├── Edge                     ★★★★★
├── Conditional Edge         ★★★★★
├── Command                  ★★★★★
├── Send                     ★★★★☆
├── Checkpointer             ★★★★★
├── Store                    ★★★★☆
├── Interrupt                ★★★★★
├── Human-in-the-loop        ★★★★★
├── Subgraph                 ★★★★★
└── Durable Execution        ★★★★☆

其中最重要的是建立这个认知：

Agent ≠ Prompt + Tool

复杂 Agent 更接近：

Agent
=
State
+
Workflow
+
Control Flow
+
Tool
+
LLM
+
Persistence

十四、最容易混淆的三处

Tool

不是「LangGraph 没有 Tool」，而是：

LangChain → Tool 抽象
LangGraph → Tool 执行与调度

Agent

不是「只有 LangChain 能写 Agent」，LangGraph 完全可以手写。区别是：

LangChain → 标准 Agent，开箱即用
LangGraph → 自定义 Agent，自己控制流程

Workflow

这里是 LangGraph 明显取代 LangChain 历史地位的地方。过去常见的 Chain、AgentExecutor、RouterChain、SequentialChain，现在复杂场景更自然写成 StateGraph。

十五、最简单的选型规则

场景 1：普通 Tool Agent

LLM
↕
Tools

优先 LangChain create_agent，没必要手写 Graph。

场景 2：复杂 Agent

例如意图识别 → 规划 → 检索 → 执行 → 评估，评估又带 retry / human review / tool / answer 分支。优先 LangGraph。

场景 3：高度定制

用 LangGraph + 原生 LLM SDK，LangChain 可以完全不使用。

十六、最终的生态架构认知

可以把现在的 LangChain 生态理解成三层：

┌─────────────────────────────┐
│         Deep Agents         │
│ 完整 Agent Harness / 高层能力 │
├─────────────────────────────┤
│          LangChain          │
│ Agent SDK / 标准组件 / 集成   │
├─────────────────────────────┤
│          LangGraph          │
│ Runtime / State / Workflow  │
├─────────────────────────────┤
│        Model Provider       │
│ OpenAI / Claude / Gemini... │
└─────────────────────────────┘

也可以采用更轻量的架构：

业务代码
   ↓
LangGraph
   ↓
原生模型 SDK

十七、一句话记忆

LangChain —— 提供「Agent 用什么」：Model、Message、Tool、Middleware、Structured Output、Standard Agent。

LangGraph —— 决定「Agent 怎么运行」：State、Node、Edge、Loop、Checkpoint、Interrupt、Subgraph。

收束 LangGraph 取代的是 LangChain 很大一部分历史上的流程编排能力，而不是取代 LangChain 的整个 Agent SDK 与生态。